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Abstract 


Recent advances in information technology have increased the need for users to 
share information. This means that users must be provided access to multiple 
databases even if they are under different database management systems and 
on different computers. Multi(iatal)ase systems act as a front-end to multiple 
databases. The fact that the databases can be heterogeneous in nature has 
given rise to languages for nuiltidat abase systems. Such a language typically 
provides users facilities to access data from more than one database. In this 
thesis, we discuss the design and im|)lementation of a feature for retrieving data 
from multiple databases with a single query. In the process, we also look at 
strategies for evaluating such an inter-database query. 



Chapter 1 


Introduction 


The traditional approach to data ])rocessiug lias been to centralize the data of an 
enterprise under a single database management system (DBMS). The database 
approach distinguishes between data description and data manipulation to fa- 
cilitate data classification. Such a separation enables a system to achieve a 
high degree of data independence thereby allowing easy extensibility to the sys- 
tem. There are other objectives of a DBMS which include providing procedural 
and non-procedural interfaces, minimal redundancy and storage space, data in- 
tegrity and control of concurrent accesses. Database systems offer to the user, 
high-level primitives for data management and automatically perform some ba- 
sic functions. They not only allow a non-redimdant. unified re])re.sentation of 
all data managed in an enterpri.se but also provide efficient methods to access 
and manipulate the data. Such database .systems often serve critical functions 
and represent significant investment for organizations. In today's information 
age there is a great need for sharing information. This implies that a user must 
be provided access to several databases even if they are under different database 
systems or on different computers. In many cases, there is a need for informa- 
tion exchange on a regionwide basi.s for the convenience of users. This means 
that globally important information e.xists in separate local databases that may 



be incompatible, thus making the existing data inaccessible to the general user. 
The incompatibility may arise because of different data models or access lan- 
guages. Major advances in computer network technology has made it possible 
to connect the databases residing on multiple computers and to access the data 
across the network. This has led to the conjecture that the next level of com- 
puterization is global, distributed .systems that can share information from all 
participating data stores (sites). It is unreasonable to expect all systems to be 
converted to a single common data model with a single access method. It is also 
unreasonable to expect users to remeinl)or multiple access paradigms in order 
to use the separate databases. Mult idal abases provide users with a common 
interface to multiple databases with minimal imiract on the existing function of 
these databases. 

There is a growing need for user-friendly global information sharing in recent 
times. There are several solutions to this. User requirements, existing hardware 
and software, and the amount of resources available will decide which solution 
is appropriate for a given environment. The solutions can be classified accord- 
ing to how tightly the global system integrates the local DBMSs. A tightly 
coupled system means that the global functions have access to internal DB.MS 
functions. Hence global functions may have priority over local functions so that 
local DBMSs do not have full control over local re.sourres. In a more loosely cou- 
pled system, the global functions access the local functions through the DBMS 
user interface. Global synchronization and efficiency are consequently reduced. 
The most loosely coupled system has an application layer residing above the 
local DBMS user interface. Here the site autonomy is maximum for each local 
DBMS. The most tightly coupled information-sharing system is a distributed 
database system. A distributed database is a collection of logically related 
data, distributed across several machines interconnected by a computer net- 
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work. Distributed databases are typically designed in a top-down fashion. The 
local DBMSs are homogeneous, i.e. they use the same data model and present 
the same functionality. The system maintains a global schema which represents 
the total information in the system. Users can submit queries over the global 
schema. Since all the local DBMSs are alike in functionality, performance can 
be increased by exploiting parallel proces.sing and redundancy capabilities of 
multiple machines. 

Global-schema multidatabases are more loosely coupled than distributed 
databases in the sense that there i.s a user interface of the local DBMS. There 
is a close cooperation between sites in maintaining the global schema. These 
are typically designed in a bottoni-up fashion and can integrate pre-existing 
databases without modifying them. Since the local schemas can be different, 
the system must provide mappings between different local schemas and the single 
global schema. The mappings may be simple as in the case of name mappings, 
or complex as in the case of structural mappings. 

Multidatabase language systems are more loosely coupled in that there is no 
explicit description of the total information in the system. The multidatabase 
system supports all functions, e.g. query proces,sing. by providing query lan- 
guage tools to integrate data from the separate databases. 'I'hese systems can 
integrate preexisting databases which may be heterogeneous in nature. The 
heterogeneity may mean different data models or differing implementations of 
the same model. The language of the multidatabase system provides special 
functions to map data from the different databases to a model and represen- 
tation meaningful to the user. Some semantic heterogeneity usually exists at 
the common model level in the sense that similar syntactic definitions may have 
different semantics. This is the consequence of the database administrator’s 
autonomy to tailor data to his needs. The language should provide tools to 
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eliminate this heterogeneity. Finally, interoperable systems are the most loosely 
coupled systems for information exchange. Global function is restricted to data 
exchange through message passing and local systems may include other types 
of information stores like expert systems, etc. 

One of the major issues which must be handled in a multidataba.se system is 
that of query processing. W'hen querying a relational database, the user typically 
specifies the desired result without specifying the access paths. The DBMS 
determines how to access the data by a])plying a (iiierv ]>rocessiiig algorithm that 
produces an access plan for a given ciiicry. The objective of query processing 
is to execute queries in such a way so as to minimize the cost of execution. 
For a centralized database system, the cost is usually the sum of the CPU 
and 10 costs. The problem of selection of the best access plan is known to be 
computationally intractable for genera] queries [Hevner87]. Hence heuristics are 
used to simplify the problem and obtain a quasi-optimal solution [Hurson91]. 
Thus the role of the query processor is to map a relational calculus query into a 
near-optimal sequence of lower-level operations acting on relations. Parameters 
which influence this phase of processing include the choice of physical storage 
model and the complexity of databa.se operations. The optimization of queries 
can be static or dynamic. Static optimization is done before the execution of 
a query. The main advantage is that it is performed once for many executions 
of the same query. This is important when database queries are embedded in 
application programs. On the other hand, dynamic optimization provides exact 
information on the sizes of intermediate results and hence can determine the 
optimal strategy. The last step is the execution of the produced access plan to 
answer the query. 

Retrieving information from a collection of independently designed databases 
is a difficult task. Access to data requires planning to control the time required 
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to process a query. A user submits a global query which in the multidatabase 
case contains all the information necessary for retrieving local data. The query 
is decomposed into a set of subciucries - one for each DBMS that will be in- 
volved in query execution. Each of these subciueries may in turn be executed 
after further decomposition. The query optimizer creates an access strategy to 
evaluate the query. The number of strategies for executing a single query in a 
distributed system is far more than in a centralized system. The cost function 
to be minimized is the sum of the CPT. 10. and tlie communication costs. The 
communication cost is the lime needed for ship|)ing data between sites partici- 
pating in the execution of the (|uory. The cost function can also be the response 
time of the query in which case the parallel execution of operations is max- 
imised. Then the access strategy is executed and the results combined to form 
a response to the original query. Initial query processing usually occurs at the 
site where the query is submitted, although some systems transmit the queries 
to designated servers for processing. 

In the next chapter, wo describe multidatabase systems in more detail. We 
also examine the different approaches in constructing a multidatabase system 
and the capabilities of eacli kind of system. In Chapter 3, we describe our 
multidatabase system and the facility which it inses for inter-database joins in 
a heterogeneous environment. Chapter 4 reviews some distributed query opti- 
mization algorithms and presents an algorithm for optimizing query execution 
in our system. Chapter 5 contains the conclu.sions of this work. 

Appendix A contains our sample local and remote databases. Appendix B 
shows some example input queries and their response. 
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Chapter 2 


Multidatabase systems 


The use of different DBMSs has proliferated in recent times. This has resulted in 
a scenario wherein there exist database.s which have to be interconnected to form 
a multidatabase system. The individual specifications have to be integrated in 
a bottom-up manner to generate a global specification. There are basically two 
approaches to this. 

1, Global schema approach 

2. Multidatabase language approach 

2.1 Global schema approach 

The global schema approach to mult idal abases makes global access quite user- 
friendly [Landers82]. Global users sec a single large, integrated database. The 
global interface is independent of all heterogeneity in local DBMSs and data rep- 
resentations. Global database administrators (DB.A.S) are required to design the 
global schema. They must have extensive knowledge of all the input schemata 
and user requirements of the global system to decide how to integrate the lo- 
cal schemata. Each of the local schemata is assumed to be optimized to local 
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requirements. An optimal design for global requirements can take into account 
local optimizations but cannot change them. Hence, the global DBA must also 
understand the local optimizations before deciding on the global schema. 

2.1.1 Design of global schema 

There are two stages of design, namely, schema integration and data integration 
[D aval 84]. 

Stage I: Schema integration 

1. The first step is to identify a common data, model for the global schema. 
The selected data model and query language should have the following 
properties; 

• They should allow a siinirle translation from the data models and 
query languages of the DBMSs constituting the heterogeneous sys- 
tem. 

• They should be suited to represent data and processing of component 
databases conveniently. In particular, the query language should pos- 
sess 'set-oriented’ primitive.s. This e.xcludes the choice of comple.x 
data models and procetlural languages. 

The relational model is the most widely used for this purpose, although 
variants of the entity-relationship model have been used in some instances. 
If a component schema is defined in terms of a different data model, it 
must be specified in the global schema data model. This step is called 
schema translation. 

2. The similarities in component schemata should be recognized. Matches 
can be recognized because of structure similarities of overlapping portions 
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of schemata. Matches can be deduced from similarity of data in the pre- 
existing databases. All the matching portion of schemata can then be 
directly reteiined in the global schema. 

3. Integration should identify conflicts in local schemata and resolve them. 
The types of conflicts are: 

• Naming conflicts - There are two types of naming conflicts. Synonyms 
occur when data objects which represent the same objects in the real 
world have been given different names in the two schemata. This 
is handled by giving same names to such entities. Homonyms occur 
when data objects with the same name correspond to different objects 
in the real world. In this case, the entities are given different names 
in the global schema. In both ca.scs. name correspondence tables are 
stored as part of the definition of the global schema. 

• Scale differences - The same function values might be stored using 
different scales. The data should be retrieved using the more precise 
scale and the conversion formula stored as part of the global schema. 
In more complex situations, the conversion might require an arbitrary 
DB.‘\-defined procedure. 

• Structural differences - These stem from different design choices for 
the local schemata. A real world object might be an entity in one 
schema and an attribute in another. Since a few structural differ- 
ences can be handled by generalization, complex query modification 
procedures need to be written in most cases and these are stored as 
part of the global schema. 

• Domain differences - Here, some entities are not represented in one 
of the schemata. Detection of these differences is accomplished by 
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comparing source databases and noting inconsistencies. These should 
be stored in the global schema. 

Apart from resolving these differences, it is also important to define any interde- 
pendencies between objects in different databases. Several methods havg been 
suggested to aid in defining these interdependencies and algorithms have been 
proposed to ensure that the definitions are optimal and consistent. This also 
requires an e.xtension of the cai)ahiliiie.s of traditional DBMSs in the direction of 
more sophisticated mullidatahase sysienis. For exam])le. interactive tools have 
been developed to assist DB.\s in schonia integration [Sheth89]. Such tools 
collect the information required for integration, perforin essential bookkeeping, 
and integrate schemata according to the semantics provided. 

Stage II: Data integration 

Once the structure of the global schema has been decided upon, its extension 
must be defined in terms of the extensions of the local schemata. But the 
extensions of the local schemata might present a conflict on the values of some 
functions. Several solutions have been proposed for this problem. One is to 
present all the conflicting data and the .sources of each of them. .Ainother is to 
present the most recent value. 'I'liis method requires time-stamping of update 
operations. A third method is to present the value from the most reliable system. 
The assumption underlying this is that it is possible to determine the reliability 
of individual sites. 

2.1.2 Maintenance of global schema 

A global schema representing several database schemata can be produced by 
integrating two schemata initially and then integrating the rest one by one with 
the previous partial schema. Since a global schema can be a very large object, 
it may be difficult to replicate it at sites with minimum storage facilities. Some 
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systems solve this problem by replicating the global schema at specified server 
sites. This means that queries can be processed only at these sites, which may 
not be very convenient. Global DBAs must maintain the global schema in the 
face of changes to local schemata. The construction of the global schema should 
be such that any changes to local schemata should not significantly alter the 
global schema. However, addition or deletion of an entire database can cause 
enormous change. If the global schema is replicated at several sites, changes to 
all of them must be effected in as short a duration as possible. Otherwise, it 
can lead to inconsistent or invalid information. 

2.2 Multidatabase language approach 

The multidatabase language approach [Hurson91] is used to resolve some of 
the drawbacks of the global schema approach, sucli as the development time to 
create the global schema, large maintenance requirements, huge storage require- 
ments, etc. In the global schema system, it is the responsibility of the global 
DBA to perfotpi the integration. The DBA lias total control over the data. 
A multidatabase language system transfers the integration responsibility to the 
user. To aid the user, it provides many functions and a great deal of control 
over the data. In this case there is no global schema. The user will see multiple 
autonomous schemata. So. a basic ro(|uireinent for a multidatabase language 
is to define a common name space acro.ss all component schemata. A common 
name space can still provide some measure of location transparency if object 
names are independent of the site they reside at. 

Most of the language extensions beyond standard database capabilities are 
involved with manipulating information repre.sentations. Queries to multiple 
databases, without a global schema, are called multidatabase queries. Since rep- 
resentation differences exist when the user submits such a query, llie language 
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must have the capability of transforiuiiig source iiiforiiiatioii into the represen- 
tations required by the query. In this context, it is particularly desirable to 
make the multidatabase language non-procedural. The multidatabase system 
should also be capable of making good implicit decisions in interpreting what 
the user wants to accomplish and providing appropriate functions. The system 
will be easier to use if it can, by default, handle more complexity. The user may 
be working with multiple equivalent objects with slightly varying attributes. If 
the system can apply a single operation to all the data objects with consistent 
results, the user can give the objects a group name and invoke the operation 
with a single command. This is one of the important features of a multidatabase 
language. This can lead to support for implicit join capability wherein the user 
has to specify only the result format, and the system figures out which relations 
to join in order to produce the required result. 

The multidatabase user need not have a knowledge of all the component 
schemata. He can acquire a knowledge of the databases dynamically as need 
arises. This is not a complex task in general because the user usually has some 
knowledge of the conceptual universe he is dealing with. The multidataba.se 
language should provide functions to display what information is available from 
the various sources. This is particularly important bacause the sheer size of 
available data will make the task of finding necessary data difficult. The lan- 
guage also typically provides the ability to limit the scope of a query to the 
pertinent local databases. 

2.2.1 Features of a multidatabase language 

A multidatabase language typically provides features not found in traditional 
DBMSs [Litwin87]. Some of these features are discussed below. 

Multiple queries are intended for situations where various databases model the 
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same universe. Then the user may wish to broadcast the same manipulation to 
severaJ databases. Multiple queries are formulated through multiple identifiers 
or through options on the target list. A multiple identifier is a name shared by 
severaJ attributes or relations. Consider, for example, the following query in the 
multidatabase system language (MDSL). 

open M G 
-range (y R) 

-select y 

-where (y.type = "Chinese") 

Here, tlie designator 'R' is the multiple identifier of the ‘R' relations in both 
the M and G databases. The result of such a query is a set of two relations 
where each relation inherits the database name its attributes come from. 

Options in the target list allow the user to specify attributes which may not 
exist in some of the schemata. Traditional DBMSs assume that all the attributes 
in the target list of a query are present in the schema of the addressed database. 
A list of the form . . . la,, indicates that only one of the Ui’s should be 

chosen. The choice follows the list order. Thus, if u\ is an attribute in schema 
1 and ^2 Is an attribute in schema 2. the target list selects the corresponding 
attributes in both the schemata. .An attribute of the form ‘"a* indicates that 
‘a’ is optional. 

It is possible to define aliases and abbreviations for databases names. This 
helps in resolving name differences between databases. A name is allowed to 
refer to multiple objects from different databases if the objects are semantically 
equivalent. This implies that an operation on a named object may actually 
cause multiple operations on several databa.ses to occur. 

MDSL allows the user to define dynamic attributes. A dynamic attribute 
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is a temporary attribute defined by a mapping from existing attributes. It is 
dynamically defined in a query and is unknown to any schema. It is used to 
accomplish transformations in data formats. It can also be used to abstract 
attribute values from multiple sources into a single set of values. However, 
representation transformations need not be performed for every query, so the 
dynamic attribute need not be accessible across queries. 

A multidatabase language should have the ability to present results in a va- 
riety of formats. When multij)le data sources are used, a user may wish to see 
all the results produced by each source. Also, the user may want the system to 
"calculate'' a result from a sot of results and present this value. In either case, 
the system should have the ability to present values in a format different from 
the one in which they are stored. 

Another important feature of such a language is to facilitate inter-database 
joins. This is necessary when information in several databases are to be related. 
To select data from several databases with a single query, the target list should 
contain attributes from the different databases. This feature is an essential part 
of any multidatabase query capability. 

In the following part of this report, wo discuss the design and implementation 
of a facility for inter-database joins in an existing query language for a hetero- 
geneous system. Once a query which involves inter-database joins is submitted 
to the system, it has to be processed efficiently. We show how such a query can 
be processed in our multidatabase system. 
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Chapter 3 


An experimental 
multi database system 


Our multidatabase system consists of two databases. Both the databases are at 
the same site. In this sense, they are logically distributed databases. Both the 
databases use the relational model, but are heterogeneous in nature. One of the 
databases uses an INGRES database management system while the other runs 
on a HP SQL database manageniont system. The INGRES system supports 
updata capability. This means that the user can create tables in the INGRES 
database as well as query them. On the other hand, the HP SQL .system sup- 
ports only retrieve capability. Hence, data can only be retrieved from the HP 
SQL database. The multidatabase user submits a global query to the INGRES 
system for processing. This query can contain references to data residing in HP 
SQL tables. We provide a facility for distributed processing wherein data at 
different sites in a heterogeneous environment can be brought together at the 
query site in order to answer a query. In our case, the query site is the INGRES 
system. Since the user does not have direct access to the HP SQL system, we 
provide an application layer above the INGRES system which issues commands 
to query the HP SQL tables. The data thus retrieved is inserted into specially 
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created tables in the INGRES system. The figure below shows the architecture 
of our system. 



We present a brief overview of both the DBMSs. 


3.1 Overview of INGRES 

INGRES is a relational database manageiuonl system which provides an exten- 
sive set of built-in functions for assisting in the process of developing database 
application [DateST]. The major subsystems in INGRES are: 

• INGRES/ QUERY - database retrieval/update, data entry 

• INGRES/REPORTS - report definition and report writing 

• INGRES/GRAPHICS - business graphics 

• INGRES/FORMS - form definition and editing 

• INGRES/APPLICATIONS - application generation 






All these subsystems constitute the INGRES frontends. INGRES froutends 
are form-based. A form is a display- screen version of a familiar paper form which 
can be used for both input and output. The process of interacting w'ith a forms- 
based system or application is referred to in INGRES as visual programming. 
These forms-based systems provide facilities for data entry and maintenance 
and for building customized applications. 

The INGRES backend provide.s all the basic DBMS functions and handles 
ciuery processing in the l.NtiRES system. INGRES itrovides twoquery language.s 
to the user - QUEL and SQL. These languages provide a high-level of abstraction 
which increases the user itroductivity. A query language user always operates 
within the context of a single database. Hence, the system does not allow a 
user to manipulate data in a non-INGRES database at a remote site. Often, a 
group of SQL statements are dispatched to INGRES for processing in an atomic 
fashion. Either all the statements are processed as a group or none at all. Such 
a group of statements is called a transaction. Transaction processing ensures 
database integrity. The savepoint feature ensures that if any errors occur during 
processing, the correction is limited to those erroneous parts of the database. 
The rollback feature is responsible for undoing the changes to the database. 

INGRES provides several system-level commands which operate at the level 
of the machine's operating system. Terminal Monitors are provided for each of 
the query languages which support interactive access to an INGRES database 
via its respective language. INGRES provides preprocessors for several host 
languages. There are commands which deal with various aspects of performance, 
optimization, and recovery. Each INGRES system supports one special database 
called the database database (DBDB), together with several user databases. 
The DBDB is used for control purposes. The INGRES system provides utilities 
which operate on the DBDB. These can be used only by the system manager. 
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INGRES provides four levels of support for distributed processing. They 
allow several INGRES sites to be connected together in a network. They also 
allow an arbitrary collection of tables from the local databases to be defined as 
a distributed database for data manipulation purposes. 

The query language of INGRES can be used interactively and as a database 
programming language. This means that SQL statements can be embedded in 
a host language program to perform databa.se operations. 

To sum up, the advantage of INGRES is simplicity which trainslates into 
easy usability and productivity. Other salient features are high-level languages 
which can be used in dual mode, forins-based sub.systems for ease of application 
development, dynamic data definition facilities, and the ability to operate in 
several environments. 

3.2 Overview of HP SQL 

HP SQL is a relational database management system which allows a user to 
create relational databases and write application programs to serve them. It 
provides the basic DBMS functions and few extensions beyond it. The query 
language provided by the system is SQL. Each HP SQL database is associated 
with a DBEnvironment. Before a SQL statement can access a HP SQL database, 
the user has to identify the cnviroimieni in which accesses will be performed. 
SQL can be used interactively or embedded in a host language (such as C). 
An embedded SQL program has to be preprocessed before it can be executed 
against the database. During preprocessing, the preprocessor needs to access the 
same DBEnvironment which the source code will access at runtime. To access 
more than one HP SQL DBEnvironment from the same program, the program 
must be separated into different compilable sections. Each section must access 
only one DBEnvironment. and must be preproces.sed and compiled separately. 
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Finally all the compiled modules can be linked together to create an executable 
program. HP SQL authorization governs who can maintain a program that 
accesses a DBEnvironment . 

HP SQL has the concept of sections. A section coiisi.sts of HP SQL instruc- 
tions for executing an SQL command. A section serves the purposes of access 
validation and access optimization. By creating and storing sections at process- 
ing time rather than at runtime, performance is improved. 

HP SQL allows a user to manii)ulate databases in several native languages in 
addition to the default language. If the proper message files have been installed, 
HP SQL displays prompts, messages, banners, etc. in the selected language, and 
displays dates and times according to local customs. It also accepts responses 
in the selected native language. 

The system does not provide any support for distributed processing. In this 
context, it supports centralized database management. .^Iso, no special system 
utilities or interfaces are provided. 

SQL commands that are not known until runtime can also be processed by an 
application program. Such commands, called dynamic commands, are entered 
by the user at runtime. The commands are passed onto the system in a character 
array variable. HP SQL converts t hese commands into executable inst ructions at 
runtime. These instructions are deleted at the end of the associated transaction. 

In short, HP SQL is a simple database management system which can be used 
for managing databases of relatively small sizes. 

3.3 Inter-database joins 

We describe a facility for inter-database joins in our multidatabase system which 
we have described above. The access languages of the two system.s are different 
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in their functionality. We select the query language of INGRES, SQL, as the 
language of our system. This means that the user submits a query on the IN- 
GRES system. The user does not have direct access to the HP SQL database, 
except possibly through applications which serve the HP SQL database exclu- 
sively. We refer to the INGRES database as the local database and the HP SQL 
database as the remote database. 

SQL provides the SELECT statement to retrieve data from a database. The 
multidatabase u.ser may want to manipulate data from the local database only 
or data jointly from the remote database. To specify data from the remote 
database, the database name is used as a prefix for unique identification of data 
objects. This implies that database names are unique in our system which is 
indeed the case. The local databa.se name need not be specified in the query 
because, by default, all data objects referenced in the query are considered to be 
from the local database. To identify the database name to the SQL parser, we 
prefix the databcise name with a 'S' sign. Thus, the way to access an attribute 
in the remote database is to have a reference of the form 

$DB-NAME . RELN-NAME . ATTR-NAME 

where DB-NAME is the name of the remote database. Prefixing the database 
name also accounts for the case where relations in different databases have the 
same name. This is not unusual in a mullidatabase environment , especially if 
the databases model the same universe. 

This feature provides the ability to perform inter-database joins. A join op- 
eration allows the user to compose two relations in a generalised way. We 
normally specify the joining attributes in the WHERE clause of the SELECT 
SQL statement. A clause specifying an inter-database join will be of the form 
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$DB-NAME1.RELN-NAME1.ATTR-NAME1 <operator> 

$DB-NAME2 .RELN-NAME2 .ATTR-NAME2 

In our multi database system, we have only equijoins which means that the 
operator above is If one of the joining attributes is from a local relation, 
the form of the clause will be 

$DB-NAHE.RELN-NAME1.ATTR-NAME1 = RELN-NAME2.ATTR-NAME2 

Since a query submitted by the user may contain references to the remote 
database, it is first input to a query preprocessor. If tlie query contains only local 
references, it is output without any modification so that it can be executed by 
the local SQL processor. If the query contains references to the remote database, 
the local system has to access the data in the remote database. We solve this 
problem by downloading the remote database data to the local database. This 
is a popular approach adopted in many heterogeneous environments and also 
in workstation/server environments. Specialized programs have been developed 
which download portions of a database into a workspace and load it in a target 
database in an identical manner, retaining all indexing information. This process 
of downloading creates a tenijrorary relation in the local database which needs to 
exist till the execution of the query is completed and the final answer presented 
to the user. The original relation name is retained for the temporary table. Since 
it is now a local table, the database name need not be prefixed. To indicate 
that it is a temporary relation, we prefix the relation name with a non-standard 
prefix which, in our case, is the sequence of alphabets ‘ZZ’. Hence, a reference 
to a remote relation is transformed to a reference to a local relation in the user 
query. For example, a clause of the form 

$DB-NAME.RELN-NAME1-ATTR-NAME1 = RELN-NAME2 . ATTR-NAME2 
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will, after transformation, be of the form 

ZZRELN-NAMEl.ATTR-NAMEl = RELN-NAME2 . ATTR-NAME2 

The query preprocessor replaces all references to the remote database in the 
input query with references to corresponding temporary relations in the local 
database. This modified query is input to the local SQL processor for execution. 

Before the query can bo executed, the data from the remote database has 
to be transferred to the local database. Connection procedures, and transfer 
of data are transparent to the u.sor. The simplest technique is to move all the 
data from a remote table to its corresponding local table. This is not acceptable 
because large amounts of data may have to be transferred and large amounts 
of temporarystorage might be required at the receiving site. Also, all the data 
in a table might not be necessary in answering a query. For example, in a 
relation which appears in a join clause, only those tuples which satisfy the join 
condition are candidates for further processing. In moving data from the remote 
database, it is particularly useful to identify the data which is not necessary so 
that it need not be shipped. Query processing techniques exist which aid the 
user in identifying the necessary portions of data. We use these techniques 
to develop a procedure which reduces the amount of data transferred between 
databases. The procedure and its implementation form the topic of the next 
chapter. 
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Chapter 4 


Query processing 


Query processing refers to the process of executing a query which results in 
a response to the query. Efficient processing of a query implies that a cost 
criterion must be satisfied while answering the query. A number of cost crite- 
ria can be used as objectives of query processing optimization. e,specially in a 
distributed environment [Hevner87]. Some of them are to reduce the number 
of data transmissions, to reduce the amount of data transferred, to minimize 
the response time to the user, to reduce the total resources used by the query, 
to improve system throughput, to equalize the workload at all .sites, etc. In 
our multidatabase system, we u.so a strategy which reduces the amount of data 
transferred between the databases. 

We have mentioned in the previous chapter that a ciuery containing remote 
references is modified to a query containing only local references. In the process, 
temporary relations are created in the local system which contains data from 
the remote database. Te retrieve the remote data, a query has to be executed on 
the remote database. Typically, for a query executed on the remote database, a 
temporary table is created at the local site and the data retrieved by the query 
is loaded into the newly created table. This means that the original query has to 
be transformed into a set of queries of which one is the modified input query to 
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be executed locally, and the rest are ‘generated’ queries to be executed remotely. 
In a general situation, if N is the number of remote relations referenced in an 
input query, N queries are executed at the remote site. But in some cases, M < 
N queries may suffice to move all the required data to the local database. We 
first identify the relations to be moved to the local database. We next present 
an algorithm which performs a reduction on the size of these relations before 
they are shipped. The SQL query which we consider is of the form 

Select T(S) 

From F(S) 

Where Q(S) 

Here, T(5) is the target list which represents the list of attributes being selected 
by the query. 

F{S) is the list of relation names from which the attribute.s are selected. 

Q(S) is the qualification of the query. We restict Q to be a list of predicates 
which are in conjunction with each other. Typically, Q is of the form 

Pi AND P 2 AND . . . AND P„ 

Queries can be represented in several forms for ease of processing. A chosen 
form should be powerful enough to express a large class of queries and it should 
provide a well-defined basis for query transformation. Relational calculus and 
relational algebra are well-known representation forms. Another representation 
form for queries are graphs. The visual representation of a query contributes 
to an easier understanding of its structural characteristics. In addition, graph 
theory offers several results useful in the analysis of graphs. We present two 
graph models of a query [BernsteinSl], viz. join graphs and query graphs. 
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4.1 Join graphs 


For a query S with qualification Q, we define the join graph to be a node-labelled 
undirected graph J(V, E) where 

V = I A is a domain of i?,} 

and 

E = {(Ri.A,Ej.B) I = Rj.B) is a join clause in Q} 

For example, the join graph for the qualification 

= Ji-i.b) AND (H^.d = AND (R^.b = R-^.c) 
is shown below. 



The join graph simply represent. s the joins in the qualification by edges in the 
graph. A join graph is total when it contains ail possible edges between vertices. 
A join graph is reduced when some of the edges between some vertices are 
missing. Two types of reduced join graphs are particularly important [Ceri84]. 

1. A reduced graph is partitioned if the graph is composed of two or more 
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components (subgraphs). 


2. A reduced join graph is simple if it is partitioned and each component has 
just one edge. 

A simple join graph is important in query optimization. A pair of relations 
which are connected by an edge in a simple join graph have a common set of 
values of join attributes. If both the relations reside at the same site, the join 
clause can be employed to restrict tlie number of tuple.s for further processing. 

4.2 Query graphs 

For a query S with qualification Q. we define the query graph 6’(l’s.£'s) as 
= set of all relations referenced by Q 
Fj = {[R,.Rj) I i 7 ^ j and a clause of Q references relations /?, and 
Rj) 

Since more than one join is possible between two relations, G is a mulligraph 
in general. For example, the query graph for a query with the following qualifi- 
cation 

(Ri.a = .-'VND ( R.iR = A.M) { Ih-b = IM 
is as shown below. 
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Several semantically equivalent expressions may exist for a given query. One 
source of difference between two equivalent expressions is their degree of redun- 
dancy. A straight-forward evaluation of a redundant expression would lead to 
the execution of a set of operations some of which may be superfluous. There- 
fore, query optimization aims at tlie eliminatioji of redundancy by means of 
transforminga redundant expression into an equivalent non-reduiidant one. 

Consider a query S whose qualification is given by 
= II 2 .B) ANT) {H 2 .B = /?3.r) AND 
The query graph for this query shows a cycle. 



• We note that can drop any of the clauses in the qualification without 
altering the scniantich of th<* qu(‘ry. Removing the last clause, for example, 
results in the qualilicatiun 

{/?i.T = K2-B) AND (R2-B = Ih^C) 

which has the following query graph. 
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This graph is acyclic in nature. The property of the cycle that permits us 
to drop one clause is that each relation participates in the cycle with only one 
joining domain, ('onsequently, wo cla.ssifv queries into two groups. A query is 
a tree query if its query graph is a tree or if it is equivalent to a query whose 
query graph is a tree. All other queries are cyclic queries. 

A reducer is an operation that can be applied to reduce the cardinality of its 
operands. A full reducer fully reduce.s its operands in the sense that it out- 
put.s only those tuphs which are re<juirect to answer a query. It is useful to 
identify when full reduction is possible for a query. Query graphs help in this 
identificat ion proa*».. 

4.3 Optimization algorithms 

The standard approach for evaluating (juories is to form the join of the relations 
involved, apply the re.strictioas to the intermediate result, and finally project it 
onto the attributes in the target list. This is diflicult if the relations reside at 
different .sites, .Several aigoritluns have been suggested for such a distributed 
enviromneiit . 

1 . Hill-clinibiug algorit lim 

This algorithm is quite general and can be applied to meet different objec- 
tives [RothnieSO]. It computes progressive refinements of an initial feasible 
solution until no beneficial modifications of the evaluation plan are pos- 
sible. The initial feasible solution is the minimum cost strategy among 
all the ones that transmit all the required relations to one site where the 
complete query is processed. This site is usually chosen as the site w'ith 
the ma-Kimum amount of data. 



2. Semijoin algorithm 

This algorithm assumes that the communication costs dominate local pro- 
cessing costs [Sacco.S2], Hence, relations are reduced as mucii as possible 
before shipping litem to tlie target database. The semijoin of R and S 
takes the join of two relations R and S and projects back on the domain of 
relation R. That is. it retrieves those tuples in R that join with some tuple 
in S. In a sense, it is a generalization of restriction: it restricts R by values 
that appear in the join domain of S. Before transmission, a projection is 
locally performed to discard unnecessary attributes, d'he advantages of 
.semijoin ov(*r the ji)iii operation are: 

• Its evaluation only re(iuire.s transmi.ssion of value lists of joining at- 
tributes instead of that of an entire relation. 

• It has a reductive effect since the result of semijoin is always a subset 
of the relation involved, wliereas a join may produce a Cartesian 
product in the worst case. 

I'he semijuin algoritlun consists of the following steps. Let A represent 
the join domaiuN of H and S. 

(a) Send 11.4(H) to the .site of S. 

(b) Locally execute the join of n 4 (R) and .S at this site resulting in 
relation \V. 

(c) Send \V to the site of H. 

(d) Locally execute the join of \V and R at this .site. 

Seinijoins are imi>ortant for hardware device.s tailored for relational query 
processing because they provide a hardware semi join instruction. The 
central problem in global reduction using the semijoin algorithm is finding 
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the ht'st soquenco of soinijoins (I'onipletonST]. The cost of semijoining 
R with relation S is assumed to ho a function of the size of the joining 
at t tribute in S which must be copied to R's site. Since duplicate values 
are removed in tlu* course of projection, the cost is estimated from the 
expected number of unique values of the joining attribute. The benefit 
is the amount by which R is reduced as a result of semijoin. Benefit 
is estimated from the total size of R and the selectivity of the joining 
attribuK*. 'i'he selectivity of an attribute is based on whether tlie attribute 
can assume* few or many valin*s. Semijoins are {)erfonned tmtil no semijoin 
is found whose benelit i.s greater than its cost. 

3. Replicate algorithiu 

This algorithm assumes that local processing costs dominate transmission 
costs (Sacco82]. Hence, tliis does not reduce relations but seeks to execute 
the user's query at several site^ in parallel. It first finds an optimal set 
of sites at %vlnrh the tiuery can he e.xecuted. .Ml sites containing relations 
referenced by the (nn*ry are potential processing sites. The sites should 
be such that there will In* comi)lete co})ies of all other referenced relations 
at each selected site. Since ik> set of sites may meet this requirement, 
relations may have to be copied between sites. The chosen set is the 
one which requires least data transfer. After necessary data is moved 
between sites, the u.ser's query is sent to each of these sites and is executed 
in parallel to provide a set of partial answers. The partial answers are 
moved to the result site where they are unioned into a teiuporaiy lelation. 
This relation may constitute the final answer or it may require further 
processing to generate the final answer. Hence, the main featuies of this 
strategy are that it enhances parallelism, and permits the local DBMS to 
perform more local optimization. The strategy is more efficient if theie is 
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a grcatcT degrw of replication of data. 

4.4 A join-based algorithm 

When local processing costs are considered along with transmission costs, it is 
advantageous to perform joins instead of semijoins [Ceii84]. Semi joins incur an 
extra join operation which, in some ca.ses. might be expensive. Joins perform 
better under the following conditions. 

1. 'riiere are f(>w attrihiiK's in the target list of the query which do not appear 
also as join attribute's of some join. 

2. Semijoins have a low .selectivity. 

If an inter-database join is specified in a query, both the relations involved 
in the join need to be pres<>nt at the .same site before the join operation can be 
preformed. This means that eith<*rhotli the relations are moved toa third site or 
one of the relations is moved to the location of the other relation. In our system, 
data from a relation in the remote databa.se i.s moved into a 'corresponding local 
table and the join operation reciuired by the query is performed at the local 
database. Thus, the objective of our query processing algorithm is to reduce 
the amount of data transferred to tables in the local database. 

4.4.1 The algorithm 

Given an input query S. our algorithm transforms it into a modified query 
L in which a i’efereiice to a remote relation P is replaced by a reference to 
the corresponding local table P! During this pi'oce.ss. it generates a sequence of 
queries to be executed at the remote database. Each of these queries R transfers 
data from a remote relation to a local relation. 
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Notation 


Por a query S. the target list is i'ei)resented by T(S) and the qualification by 
Q(S). RT(S) represents the set of remote attributes in the target list. P denotes 
a local relation while denotes a remote relation. The input query is 

S : Select T(S) 

From A , B , . . . , #M . #N . ... 

Where Q(S) 

After preprofOiSsing. the modified (juery I. has the form 

L ; Select T(L) 

From A , B , . . . , M*. N*. ... 

Where Q(L) 

The remote query H has the form 

R : Select T(R) 

From #M , #N , ... 

Where Q(R) 

We now present our algorithm. 

1. Q{I.) - Q(R) - u 

2. Represent the qualification of .S by a join graph .1^. 

U. for each connected component (.' of do 

If C does not reference remote relations, add the clause(s) represented by 
it to Q(L). Delete C from Jj. 
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If C docs not rofcrciiro loral relations, add the clause(s) represented by it 
toQ(R). 

Partition the nodes of (‘ according to the relations named by them. 

Connect all nodes representing a remote relation through a chain. Denote 
this group of nodes by C(R). 

Connect all nodes representing a local relation through a chain. Denote 
this group of nodes by C(I.). 

Add the clause! s) re|)reseiitiHl by C(H ) Q(h)- 

Add the clause(s) represented by (’(h) to Q(h). 

If C(L) = p, add the clause(s) represented by C(R) to Q{L). 

Let local-attr be any element of C(L), the set of local attributes in C. 

Let K = RT(S) n C{R). 

If K = o. let remote-attr be any element of C(R) 
else let reniute-attr be any elenieiil of K. 

If C{1.) = o. Q(l.) = (local-Jittr = remote-attr) 
else Q(L) = Q(L) AND (local-attr = remote-attr) 

R'r(S) = RT(H) U {remote-attr} 
endfor 

4. T(L) = T(S). the target list of given query. 

Group all attributes in RT(S) according to the relation to which each 
attribute belongs, ror each group, we have a query which is executed 
remotely. -All the attributes of a group form the target list of its respective 
query. Each such generated query has the same form, with the target lists 
being different in each case. For a grouj) identified by relation #P, add 





relation #P to the FROM clause of the local query L. Since we change the 
name of the transferred relation, replace each occurrence of #P in L by 
its uame-transformed equivalent r\ P' refers to the local relation whicli 
contains data from the renlote relation #P. ■ 

Correctness of algorithm 

The algorithm reduces a remote relation by applying as many restrictions and 
projections as are api)lical.>le at the remote database. Projections restrict the 
relation to the re<|uire(l attribute list.s only. Join clauses further reduce the 
relation by eliminating tuples wliich do not satisfy at least one join clause of the 
qualification. Wo also use two other techniques for reduction. 

1. Constant propagation This method propagates a constant across join 
clauses [CardarinJ^9]. For instance, the qualification 

(#M.a = B.a) .\.NI) (B.a = 10) AND (#M.a = C.b) 
is e<iui valent to the tiualificalion 

(#M.a = B.a) AM) {#.\l.a = C.b) AND (#M.a= 10) 

In this case, tlu* restriction = 10 can bo applied at the remote 

database. 

2. A join clau.se can be logically implied by the qualification by transitivity 
laws. For example, 

(A. a = #M.aj .A.ND (.A.a = #N.a) imply (#M.a = #N.a) 
whicli, clearly, is applicable at the remote database. 

Since the aliovo te(’lmique.s can be easily seen to be correct, and our algorithm 
employs only these technicjues, our algorithm correctly performs a reduction on 
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Q(L) is obtained by tlte followinp; nietliod. All join clauses in the input query 
which refer to a local table or a remote table only form a part of Q( L) directly. In 
the case of constant propagation, the join clau.se applied at the remote database 
is simply excluded from the qualification of the modified query. For example, 
the qualification 

{#M.a = B.a) AND (B.a = 10) AND (#M.a = C.b) 
is equivalent to the ciualification 

(#M.a = B.a) AND (#.\1 .h = C.b) AM) (#M.a = 10) 
as discussed above. The la.si clause is detached, thus giving the qualification 
(#M.a = B.a) AND (#.M.a = C.b) 

This qualification correctly retrieves only those tuples which would have been 
selected by the original qualification. 

In the final case, if the qualification has a cycle as in 

{#M.a = A.a) AND (A.a = B.a) AND (B.a = #M.a) 

we can drop any of the clauses; the resulting qualification is obviously equivalent 
to the abewe one. .Also, (jualifications having the same transitive closure are 
equivalent. Using the.se two properties and the fact that a clause which is part 
of a cycle and is api>lied at the remote database need not be applied twice, we 
obtain Q(l. ) for the mudifioil query. 

To illustrate, consider the c|ualificalion 

(A.a = #M.a) ANT) (A.a = #.\.a) 

The transitive closure is given by 

(A.a = #.M.a) AND (A.a = #N.a) AND (#M.a = #N.a) 


We drop the first clause, giving 



(A.a = #N.a) AND (#M.a = #N.a.) 


The second of these clauses can be applied at the remote database and hence 
can be detached, giving 

(A.a = #N.a) 

as the qualification for the modified query. It can be readily seen that the 
qualification thus obtained is correct. 

Hence, the algorithm correctly produces tlie seciueiice of querie.s R and L. 

4.4.2 Examples 
Example 1 

Consider the query S given by 

S : Select A.b 

From A, #M, #N 

Where (A.a = #M.a) AND (A.a = #N.a) 

T{S) = {A.b} 

RT(S) = o 

Q{S) = (A.a = #.\l.a) AND (A.a = #N.a) 

TliO join graph for Q(S) is as .shown bolow. 





Hence. Q(R) = (#M.a = #.N.a) 
local-attr = .^.a 
remote-attr = #.M.a 
Q(L) = (A.a = #M.a) 

RT(S) = {#M.a} 

There is one remote (jnery R given by: 

R : Select #M.a 
From #M. #N 
Where #M.a = #N.a 

The modified local query is 

L : Select A.b 
From A, M* 

Where (A.a = M.a) 


Example 2 
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Consider the query S given by 


S : Select #P.a. #R.d 
From A. #P, #R 

Where (A. a = #R.a) AND (#R.b = #P.b) 

We haveT(S) = {#P.a, #R.d} 

RT(S)= •{#P.a.#R.d} 

Q(S) = (A.a = #R.a) AND (#R.b = #P.b) 

The join grapli is as shown below. 




For the first eouipouent of the grapli. C(L) and CHR] as shown. 

c(l) c(r) 




By the algorithm, local-atir = .\.a 
reinote-attr = #Ra 
Q(L) = (A.a = #R.a) 
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RT(S) = RT(S) U {#R.a} 


For the second component, C(L) and C(R) are as shown. 

c(£) 



Q(R) = (#R.b = #P.l)) 

Q(L) = Q(L) AND (#R.b = #I>.1)) 

RT{S) = RT(S) u #1M)} 

= {#P.a, #R.d. #R.a. #R.b. #P.b} 
There are two remote queries. 


R, : Select #P.a. #P.b 
From #P, #R 
Where (#R.b = #P.b) 


Rj,: Select #R.a, #R.b, #R.d 
From #P, #R 
Where (#R.b = #P.b) 


Tlie iiKxiifu'tl local qix'iy i> 

L : Select P'.a, R'.d 
From A, P' R"" 

Where (A. a = R^.a) AND (R^.b = p'’.b) 


4.5 Implementation procedure 


The proj^ram takes a user tiuery as input and produces the modified query 
as output. The modified query i.s e.teculed to yield the final response. The 



program has been developed in the C’ language. Several data structures are 
used to represent the structure of the input query. 

Information about each of the remote relations is stored in a structure which 
has got four component fields. The C structure definition is as follows: 

struct aliastable { 

char tablename[303 : 
char localnameCSO] ; 
char aliasnaane[20] ; 
char colnames [lOO] : 
struct aliastable ♦next; 

}; 

A description of each of these fields is given below. 

• tahlename - holds the name of the remote table 

• localnaine ■ holds the name of the corres})onding temporary table in the 
local datahaM- 

• aliasname - holds any alias used by the tjuery for the relation 

• colnames - represents the names of columns which occur in the query 

One structure holds the information about one relation. .A.11 the structures 
are chained together to form a linked list. 

There is a global pointer to the aliastable, which initially is NULL. This 
pointer has the definition 

struct aliastable *aliasptr: 
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Th<* functions aliasal!oc() and freestorage( ) allocate and de-allocate storage, 
respectively, for an instance of the structure. 

We use two arrays named larray (for local array) and rarray (for remote array) 
to represent the join clauses of the query. The two arrays relate to each other 
through their corresponding elements. The clause 

(A.a = #M.b) 

is represented by the assignment statements 
larrayfi] = .A.a and rarray[i] = #M.b 

for some inde.x i. This nielhod is versatile enough to represent any kind of join 
clause that may appear in a query. We e.'ctend each clement of the two arrays to 
hold multiple names, separated by a blank. Then, for any inde.x i. the elements 
of larrayji] and rarray[i] taken together represent all the join clauses, implied or 
otherwise, present in the input c|ut*ry. The definitions of the two arrays are: 

char larray [10] [100] ; 
char rarray [10] [100] ; 

Thus, for example, the elements 
larray[.‘l] = '.A.a B.a' and rarray[;j] = 
together represent the set of join clauses 
(A.a = B.a) A.N’D (B.a = #M.a) 

When a ’’generated cjuerv is to ho executed, a call is made to a procedure. 
This procedure first creates a temporary table in the local database, whose name 
is given by the docalnanie' field in the structure for the relation in question. It 
then queries the remote table and retrieves data from it. This data is loaded 
into the newly created relation. 
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Chapter 5 

Conclusions 


The join- based algorithin which wo have presented in llie previous chapter per- 
forms well when local processing costs are comparable to transmission costs. 
This algorithm can be easily extended to include multiple databases at several 
sites. In a heterogeneous environment, not all the DBMSs provide the same 
functionality to the mullidatabase user. In such a case, the algorithm can take 
into considc'ratiou the type of capability provided by each of the local systems. 
I'ho algoritlim can also bt> used when tliere is replication of data at different 
sites. In tliis case, a copy of each relation at a particular site is treated as a 
local relation, if the site' is the query site, and as a remote relation otherwise. 
The requirement of the algorithm is that the DBMS at the query site should 
provide update capability. 


The algorithm forms the basis of a feature for inter-database joins in a hetero- 
geneous scenario. Existing query languages do not provide such a facility. This 
facility is important in a inultidatabase system, as is evidenced by a growing 
interest in mullidatabase languages. DBMSs should also provide support for 
temporary tables. It must provide facilities to dynamically define the structure 
of temporary tables, and to manipulate them without altering the state of the 
database. The temporary relations should be accessible by DBMSs at other 
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sites. This wiU enable a user to tailor the multidatabase system to his specific 
needs. 

Further extension to this work lies in the area of providing additional data 
manipulation capability for remote data. For example, update capability can 
be provided for remote tables. With this capability, alternative techniques for 
query optimization in multidatabase systems can be suggested. For instance, 
a semijoin-based algorithm may be more effective in systems where queries are 
not ad-hoc in nature. In a more general situation, query processing can in- 
volve identifying .sites with update capability and modifying the input query 
accordingly. 
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Appendix A 

Example local and remote 
databases 
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Local relation: BookS 
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Local relation: 
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Remote relation: 
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Remote relation: 
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Appendix B 


Example queries 


1. Query : List the names of courses for which a reference book has been 
issued to a student enrolled in the course. 

SQL formulation of the above query: 


SELECT C.COURSENAME 

FROM BOOKS B, REFERENCE R, ISSUE, 

$STUDDBE. ENROL E, $STUDDBE . COURSES C 
WHERE E.COURSENO = C.COURSENO AND 
C.COURSENO =R.C0URSEN0 AND R. TITLE* B. TITLE AND 
R.AUTH0R=B. AUTHOR AND B .ACCNO=ISSUE. ACCNO AND 
ISSUE. IDNO = E.ROLLNO; 

Answer: 

AI & Speech Recognition 

2. Query : List the titles of books issued to CS students. 


An embedded SQL program for the above query follows. 





f include <stdio.h> 


EXEC SQL INCLUDE SQLCA; 


fdefine ok 0 


mainO 

EXEC SQL BEGIN DECLARE SECTION; 
char title [20] ; 

EXEC SQL END DECLARE SECTION; 

EXEC SQL WHENEVER SQLERROR STOP; 

EXEC SQL CONNECT ’knkumar’ ; 

EXEC SQL SELECT BOOKS. TITLE INTO : title 
FROM BOOKS, $STUDDBE. STUDENTS S, ISSUE 
WHERE BOOKS. ACCNO = ISSUE. ACCNO AND 
ISSUE. IDNO=S.ROLLNO AND S.DEPT = »CS’ 
EXEC SQL BEGIN; 

printfC'Book Title is 7.s\n" .title) ; 

EXEC SQL END; 

EXEC SQL COMMIT; 

EXEC SQL DISCONNECT; 

> 


Answer: 

AI and Speech 



